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This  thesis  examines  tie  questions  of  user  requirements, 
design  considerations,  aid  network  environment  for  a  local 
area  network  Terminal  Management  function  in  support  of  the 
Naval  Supply  Systems  Command's  Stock  Point  Logistics 
Integrated  Communications  Environment  X£?LICE» .  Criteria 
are  developed  from  this  examination.  include  process- 
process  communication,  virtual  terminal,  and  user  defined 
screen  capabilities  as  wall  as  a  negotiated  virtual  terminal 
protocol  based  upon  a  network  virtual  terminal  concept. 
Recommended  generic  and  specific  models  of  the  Terminal 
Management  function  applying  these  criteria  are  then 
presented. 
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1.  OBJECTIVES  OF  BESE1BCH 

The  objective  of  the  Stock  Point  Logistics  Integrate! 
Communications  Environment  (SPLICEl  Local  Area  Network  (LAW) 
Project  at  the  Naval  Postgraduate  School,  Mcnterey,  was  to 
develop  alternatives  for  SPLICE  LANs.  The  thesis  submitted 
by  Lieutenant  Joesph  N.  Reinhart  III,  USMC  aid  Lieutenant 
Bicardo  Arana,  Peruvian  Navy  [Bef.  1],  concerns!  itself  with 
the  development  of  functional  desigi  specifications  for  the 
implementation  of  the  Database  and  Terminal  Management  func¬ 
tions  of  a  functionally  distributed  LAN  in  rsspor.se  to  the 
requirements  of  the  Naval  Supply  System's  store  points  an! 
inventory  control  points. 

The  objectives  of  this  thesis  research  is  to  further 
define  the  requirements  of  the  SPLICE  users  and  to  develop 
from  these  needs  a  generic  model  of  Terminal  Management  (TM) 
functions  necessary  to  support  the  services  required.  The 
rationale  for  using  a  generic  model  rather  than  a  specific 
model  lies  in  the  evolutionary  stats  of  Naval  Supply  Systems 
Command  (NAVSUP)  data  processing  objectives.  In  an  execu¬ 
tive  level  briefing,  the  SPLICE  project  office  stated  : 

Me  cannot  afford  the  luxury  of  supporting  "Navy  unique" 
software  packages  (in  tie  future*.  Me  siaoxy  cannot 
afford  the  resource  draw  (drain).  Our  policy  must  not 
allow  unique  solutions.  Our  systeas  must  fit  within  the 
technology  and  capabilities  of  the  general  AD?  market¬ 
place.  [Bef.  2] 

In  keeping  with  that  policy,  this  thesis  will  attempt  to 
recommend,  using  the  Reinhart  and  Arana  thesis  as  a  theoret¬ 
ical  foundation,  a  TM  functional  specification  capable  of 
supporting  presently  envisioned  SPLTCE  LAN  configurations. 


Copy  available  to  DTiC  does  not 
permit  fully  legible  reproduction 


while  presenting  the  capability  to  support  evolutionary 
configurations  of  the  future. 

B.  BACKGROUND 

SPLICE,  as  concieved  by  NAVSU?  describes  a  .near-tern 
system  to  provide  badly  needed  local  ar.d  system  network 
coa munication  and  management  functions  without  further  over¬ 
loading  the  present  host  system.  It  also  presents  the 
conceptual  foundation  for  respones  to  future  changes  to  both 
customer  requirements  and  technological  advances.  SPLICE 
draws  together  under  one  conceptual  umbrella  the  myriad  of 
new  applications  being  developed  independently  throughout 
the  supply  shore  establishn ent. 

SPLICE,  in  its  simplest  form,  is  designed  to  provide  a 
hardware  and  software  architecture  capable  cf  supporting  a 
wide  variety  of  interactive  application  programs  on  both 
local  and  remote  terminals.  4hen  fully  realized  this  capa¬ 
bility  will  significantly  reduce  the  proliferation  of  stand 
alone  computers  at  support  sites  presently  unable  to  obtain 
data  processing  services  otherwise. 

Significant  factors  vnich  will  determine  the  success  of 
the  SPLICE  concept  will  be  the  speed  and  accuracy  of  data 
and  fils  transfers  within  and  between  LANs  and  tae  speed, 
accuracy  and  ease  of  interactive  terminal  sessions.  It  is 
the  latter  concern  which  is  the  reason  for  this  thesis. 

NAVSUP  and  Fleet  Material  Support  Dffice  SPLICE  documen¬ 
tation  provide  detailed  information  on  SPLICE  software 
design  considerations  [Ref.  3],  systems  so ecif icat ions 
[Ref.  4],  functional  design  [Ref.  5],  and  teleco amuaciations 
plans  [Ref.  6].  References  7  and  3  provide  insight  into  the 
magnitude  and  variety  of  transactions  contained  in  typicial 
applications  which  SPLICE  will  be  expected  to  support.  As 
the  LAN  design  project,  with  which  this  thesis  is 
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associated,  is  not  constrained  bp  SPLICE  designs  and 
specifications,  the  above  references  were  used  primarily  as 
a  source  of  purpose  and  oojectives.  Reference  1  provides  a 
very  readable  synopsis  of  References  3  through  5  .  Readers 
desiring  such  information  ire  referred  to  sections  IA  ar.d  IC 
of  that  document.  In  keeping  witi  the  objective  of  their 
research,  Reinhart  and  Arana  presented  their  recommendations 
for  Database  and  Terminal  Management  functional  specifica¬ 
tions  in  support  of  a  LAS.  In  me  name  of  brevity,  a 
lengthy  condensation  of  that  thesis  will  not  oe  provided  in 
this  thesis.  Instead,  as  this  thesis  uses  the  Reinhart  and 
Arana  thesis  as  a  jumping-off  point,  later  developments 
and/or  information  that  night  modify  that  thesis  will  be 
presented  in  section  C  of  this  introduction. 

Additional  insights  into  the  variety  and  size  of  the 
tasks  expected  to  be  processed  on  the  SPLICE  LAS  were  gained 
by  personal  contacts  with  persons  attached  to  the  SPLICE 
project  office  at  NAVS3P  headquarters  in  Washington,  D.C. 
and  functional  managers  at  Naval  Supply  Centers  in  Oakland 
and  San  Diego.  The  intent  of  this  thesis,  and  therefore 
these  interviews,  was  to  establish  in  the  author's  mind  a 
generic  definition  of  interactive  processing  requirements  so 
that  Terminal  Management  (T M)  alternatives  might  be  evalu¬ 
ated.  The  results  of  these  investigative  interviews  are 
contained  in  Chapter  II  of  this  thesis. 

C.  ADDENDUM  TO  HEIN HART  AND  ARANA  I3ESIS 

In  their  background  section,  Reinhart  and  Arana  implied 
that  a  commerical  product  named  Terminal  Application 
Processing  System  (TAPS)  was  the  most  probable  implementa¬ 
tion  of  terminal  management,  database  management,  complex 
management,  and  transport  management  functions.  At  the 
time,  that  was  a  valid  assumption  and  shared  by  NA7SUP. 


also  discussed  in  section  ID  if  Beference  1  are  the 
relative  merits  of  a  high  level  database  query  language 
versus  the  interactive  application  programs  approach  of 
NA7 SUP.  The  thesis  implies  that  N&7SUP  should,  and  there¬ 
fore  has  yet  to,  investigate  the  feasibility  of  a  database 
query  language  capability  within  SPLICE.  This  author's 
interviews  and  a  review  of  NA7S0P  policy  guidance  indicate 
that  NAVSUP  has  the  eventual  development  and  use  of  such  a 
query  language  high  on  their  ADP  priority  list. 
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II.  S£Q2I81flSSI§  BlglSiIIQN 


* 

I 


A.  OVERVIEW 


The  method  employed  in 

attempting  to 

arrive 

at  a 

requirements 

definition  for 

the  Terminal  X 

anagement 

(m 

function  was 

a  series  of  interviews  using 

standard 

ques- 

tions.  The 

interviews  were 

conducted  with 

persons 

at  the 

Naval  Supply 

Centers  at  Oakland  and  San 

Diego. 

These 

centers  were  chosen  primarily  because  of  locale,  but  this 
choice  does  not  diminish  the  effectiveness  of  the  inter¬ 
views.  Between  them,  Saa  Diego  aid  Oakland,  conduct  the 
entire  range  of  stock  point  operations,  with  the  exception 
of  strategic  forces  support.  San  Diego  supports  a  major 
fleet  presence,  a  large  training  rommard,  two  major  air 
stations,  and  numerous  snore  maintenance  and  administrative 
commands.  Oakland  supports  a  smaller  fleet  presence,  one 
air  station,  fewer  shore  esta  blish  a  en  ts,  but  serves  as  a 
clearing  house  for  Western  Pacific  requirements.  Both 
centers  presently  support  remote  terminal  operations.  3oth 
have  implemented  either  or  both  IDA  or/and  APADE  to  varying 
degrees.  These  terminal  based  interactive  application 
programs  are  currently  executed  on  stand-alone  minicompu¬ 
ters,  but  their  mere  existence  allows  the  functional 
managers  using  them  to  answer  questions  not  answerable  by 
managers  without  experience  with  this  type  of  approach. 

The  impressions  garnered  from  these  interviews  are 
contained  in  section  B  beLow.  Section  C  discusses  informa¬ 
tion  gained  in  meetings  with  NAVSUP  SPLICE  project  office 
personnel.  Section  D  summarizes  tne  user  requirements  and 
associated  assumptions  that  will  oe  used  throughout  the 
remainder  of  this  thesis  in  evaluating  TM  approaches. 
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B.  STOCK  POINT  BEQ0IBE1ERT  S 


Interviews  witb  stork  point  functional  managers  quickly 
established  the  presence  of  managerial  difficulties  expected 
in  trying  to  hold  together  an  ongoing  production  effort 
based  on  established  procedures  and  technology  while  trying 
to  simultaneously  implement  a  newer  technology.  Despite 
their  tribulations,  these  managers  were  most  willing  to 
share  their  experiences  to  date  with  terminal  based  interac¬ 
tive  application  programs. 

Both  IDA  and  APADE  are  designed  :o  utilize  a  menu-driven 
form  mode  of  interactive  data  entry  and  file  inguiry/update. 
Both  have  extensive  process  options  available  to  the 
terminal  user. 

The  APADE  users,  primarily  in  the  purchasing  division  of 
the  Procurement  Department,  logicalLy  and  physically  sepa¬ 
rate  data  entry  functions  from  data  inguiry/update 
functions.  This  is  based  mostly  upon  time  constraints  of 
data  entry  and  the  volume  of  these  transactions.  The  T!1 
implications  of  this  separation  is  that  the  data  entry 
clerks  would  be  best  served  by  the  least  creative,  least 
complicated  T!1  that  would  still  support  interactive  form 
data  entry,  i.e.,  when  finished  with  one  form,  the  user 
wants  another  form  immediately,  not  a  nelpful  but  neverthe¬ 
less  key-stroke  consuming  menu.  3n  the  other  hand  their 
co-wcrkers  who  are  responsible  for  handling  a  rather  large 
number  of  document  inquiries  from  not  always  patient 
customers  would  find  the  aoility  to  split  their  screen  into 
multiple  sections  and  to  conduct  a  separate  inquiry  or 
update  in  each  section  very  helpful.  The  purraasing  admin¬ 
istrative  personnel  are  frequently  asked  to  produce 
information  (written  and  oral)  that  requires  multiple  access 
to  files  and/or  manual  manipulation  of  the  data  accessed. 
The  primary  cause  of  their  effort  is  that  they  are 
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constrained  by  the  forints,  both  display  and  reports, 
designed  into  the  system.  The  capability  to  design  a 
multiple-use  screen  and  report  fonat  at  the  terminal  is 
indicated. 

The  IDA  users,  financial  accounting,  commonly  referred 
to  as  Tripla-A,  do  not  separate  their  data  entry  from 
inquiry/update.  Each  cleric  who  has  a  terminal  has  often 
found  himself  in  the  situation  of  needing  to  view  a  record 
from  more  then  one  file.  This  situation  is  especially  preva¬ 
lent  when  reconciling  vendor  invoices  with  requisitions. 
This  need  is  presently  met  by  calling  a  cleric  who  has  access 
to  the  necessary  files  ( A  PADE  or  UADPS)  and  passing  the 
necessary  information  by  oione  --  automation  indeed! 

The  Customer  Services  personnel  primarily  interface  with 
the  UADPS  applications  residing  on  the  Burroughs  host  main¬ 
frame.  Their  interaction  with  the  computer  is  varied,  b-ut 
basically  inquiry  in  nature.  Data  entry  is  normally  batch 
processed,  and  will  in  all  likelihood^ remain  so  until  OCR 
technology  replaces  the  current  card  readers.  Because  most 
queries  are  made  to  records  stored  and  processed  in  80 
column  card  format,  a  scroll-mode  terminal  presentation  with 
the  ability  to  continually  enter  queries  and  direct  replies 
to  a  nearby  printer  is  the  near  concensus  choice  for 
terminal  interaction.  A  less  frequent  activity  conducted  by 
Customer  Services  personnel  requires  them  to  spend  hours 
researching  and  cross  referencing  records  from  various  UADPS 
and  financial  files  (now  IDA  files*  .  This  reasearch  is 
normally  conducted  by  the  most  experienced  and  senior  clerks 
and  supervisors  in  the  division,  so  it  would  seem  that 
countless  hours  could  be  saved,  not  to  mention  dollars,  if 
these  persons  could  break  away  from  the  standard  displays  to 
which  they  are  now  limited  and  set  up  a  screen  display 
suitable  for  researching  and  controlling  the  source  of 
display  input. 
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In  warehousing  and  laterial  receipt  functions,  the  use 
of  automation  has  just  begun,  primarily  in  stowage  and 
retrieval  operations.  The  day  of  tie  use  of  bar  cedes  and 
light  pens  for  receipt  processing  and  inventory  management 
is  still  somewhat  distant.  Although  there  is  good  reason  to 
suspect  that  these  devices  should  be  considered  peripherals 
and  therefore  not  within  the  purview  of  this  thesis,  the 
author  can  envision  a  scenario  where  they  would  be  direct 
inpur  devices  to  several  UADP5  application  programs.  As 
such,  the  author  has  chosen  to  include  them  in  the  category 
of  potential  terminals. 

C.  HATSOP  POLICY  AID  DI RECTI  OR 

In  addition  to  a  survey  of  stock  point  personnel,  a  trip 
was  made  to  Washington,  D.C.  to  aeet  with  SPLICE  project 
office  personnel.  The  objective  of  the  meetings  was  to  gain 
an  appreciation  for  the  direction  of  SPLICE  LA7s.  Although 
the  development  cf  a  generic  TS  model  from  requirement  needs 
is  deemed  academically  justifiable,  there  remained  the 
concern  that  to  stray  too  far  froa  the  realities  of  the 
Naval  Supply  System  would  result  in  an  academic  exercise  of 
little  import.  The  quotation  cited  in  Chapter  I,  Objectives 
of  Research  section,  convinced  this  author  that  such  a  model 
could  in  fact  be  of  use,  particularly  in  view  of  the  desire 
to  move  away  from  "Navy  unique"  software.  The  functional  TN 
model  presented  in  Chapter  17  represents  the  author's  desire 
to  produce  a  recommendation  for  the  near  future,  ana  there¬ 
fore  embraces  the  reality  of  the  SPLICE  environment  more 
than  the  generic  TH  model  presented  in  Chapter  III. 

Additional  information  gained  from  these  meetings 
included  familiarization  with  the  long-term  oojectives  of 
SPLICE  implementation.  Although  these  objectives  do  not  fit 
the  category  of  user  requirements,  taey  are  paraphased  below 
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because  failure  to  keep  them  in  mini  in  a  design  process 
increases  the  probability  that  the  resultant  design  may  too 
restrictive  to  be  of  value  in  meeting  future  growth. 

SMS2E  S£iICE  Prgieo*  D bj.er 

Data  must  be  mads  available  to  the  customer,  easily 
accessed  from  wherever  tae  customer  is  located  on  a  conti¬ 
nuous  basis  around  the  clock. 

A  distributed  data  base  must  be  developed. 

Goals  for  £A  VSOP  ADP 

All  punched  cards  must  be  eliminated. 

The  use  cf  point-of-sale  terminals  and  hand  held 
terminals  with  optical  scanning  capabilities  at  data  entry 
points. 

-  The  use  of  bar  codes  and  magnetic  strips  in  inventory 
control  and  warehousing  applications. 

D.  CONCLUSIONS  AND  ASSOHPriONS 

The  following  conclusions  regarding  the  TM  requirements 
of  users  of  the  SPLICE  LAN  are  based  upon  tne  interviews 
discussed  above  and  observations  of  terminal  use  at  stock 
points.  Assumptions  are  based  upon  the  same  observations 
coupled  with  the  author's  experience  in  stock  point 
ope  rations. 

1.  A  TM  must  be  able  to  support  a  wide  variety  of  termi¬ 
nals,  varied  not  only  in  aa ke/model,  but  also  in  operational 
characteristics . 

2.  A  TM  must  be  abLe  to  support  character,  line,  page, 
scroll,  and  form  mode  editing  capabilites  at  the  same 
terminal. 

3.  A  TM  should  provide  the  ability  for  a  user  to  locally 
format  a  display  area,  and  resultant  hardcopy  output. 
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4.  A  user  should  be  able  to  simultaneously  display 
multiple  processes  utilizing  different  application  programs. 

5.  A  TM  should  provide  the  mechanism  to  allow  applica¬ 
tion  to  application  interaction  (author's  assumption) 

6.  A  TM  should  be  able  to  support  non-interactive  data 
entry,  such  as  light  pens  and  hand-held  (author's 
assumption)  . 

7.  A  TM  should  provide  a  general  framework  within  which 
future  terminal  functions  can  be  accomodated  (author's 
assumption)  . 

8.  A  TM  design  must  recognize  the  relative  lack  of 
sophistication  cf  potential  jsers  and  the  probability  of 
high  turnover  in  these  positions. 
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HI.  i££IC£3  DP  ISaaiMt  MANAGEMENT 


A.  OVERVIEW 

In  addition  to  the  user  requirements  discussed  in 
Chapter  II,  investigation  and  evaluation  of  alternative  TM 
techniques  requires  an  appreciation  for  the  technical 
concerns  of  a  TM.  Section  B  discusses  these  concerns. 
Section  C  outlines  the  LAN  environment  assumed  for  this 
thesis.  Section  D  presents  the  author's  view  of  a  qeneric  TM 
model.  Section  E  then  explores  some  of  the  T! 1  approaches 
cited  ir.  contemporary  literature.  Section  P  contains  a 
review  of  the  TM  approach  advocated  by  Reir.hact  and  Arana 
[Ref.  1]. 

B.  TM  TECHNICAL  CONCERNS 

TM,  as  a  list  of  widely  agreed  to  discrete  functions  and 
protocols,  does  not  exist.  Rather,  there  exists  an  impres¬ 
sive,  if  somewhat  confusing,  spectrun  of  alternative  methods 
of  implementing  a  TM.  Dn  the  most  ambitious  end  cf  this 
spectrum  is  a  TM  module  which  provides  the  full  range  of 
functions  described  in  the  Presentation  Layer  (layer  6)  of 
the  International  Standards  Organization  (ISO)  Open  Systems 
Interconnection  (OS I)  reference  model.  One  of  the  many 
definitions  of  the  task  of  the  Presentation  Layer  "...is  to 
support  communications  by  providing  commonly  known,  virtual 
devices  and  commonly  known  virtual  information  to  th=» 
distributed  applications"  *  Ref.  10:  p.  227],  A  less  ambi¬ 
tious  TM  would  be  expected  only  to  "hide  terminal 
idiosyncracies  from  the  application  programs"  |Ref.  11:  p. 

484  ].  The  latter  representing  a  subset  of  the  former. 
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It  is  helpful  to  try  to  describe  the  design  concerns  of 
a  m  and  then  to  blend  the3e  concerns  with  user  requirements 
to  form  a  model  of  the  ideal  or  generic  TM  which  would 
recognize  both  the  designer's  and  user's  concerns. 

A  suggested  list  of  concerns  of  the  TM  designer  is 
found  in  Reference  12  (pp.  82-84).  These  concerns  are: 

Control  of  the  £§£ninal  gangling  -  Assuming  the  wide 
variety  cf  terminals  and  attendant  variety  cf  characteris¬ 
tics,  the  parameters  which  affect  local  handling  cf  a 
terminal  must  be  known  to  the  PM,  and  to  no  other  LAN  module 
nor  to  remote  users. 

2)  Dialogue  Ijgde  -  The  TM  should  provide  methods  for 
selecting/providing  support  for  bota  half-duplex  or  full- 
duplex  operations. 

3)  Terain al  Data  Structure  -  Like  terminal  control  char¬ 
acteristics,  the  TM  must  be  aware  of  the  data  structure 
parameters  of  the  terminal  as  well  as  the  command  language 
primitives  available  for  manipulation  of  that  structure. 

4)  Symmetry  -  The  design  of  the  TM  must  be  concerned 
with  the  desirability  of  symmetrical  forms  of  connection, 
e.g.  process-process  and  terminal-terminal  interactions 

5)  Negotiations  -  The  TM  must  provide  a  dynamic 
mechanism  ro  negotiate  the  facilities  and  parameters  to  be 
used  in  each  interconnection. 

6)  Attentions  -  The  TM  must  be  oapable  of  inter pretting 
and  handling  the  variety  of  methods  used  in  terminals  and 
processes  to  signal  "brea<",  '‘abort",  and  other  such  atten¬ 
tion  commands.  These  signals  are  normally  expedited  signals 
"out-of-band"  or  outside  tie  normal  flow  of  data. 
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C.  LOCAL  ABBA  HETSOHK  (LAI)  EBVIB3N3BNT 


The  LAN  environment  in  which  the  TH  beir.g  discussed  in 
this  thesis  will  operate  is  a  fully  distributed  LAN  based 
upon  seven  primary  functional  software  modules;  local  commu¬ 
nications,  national  coamna icat ions,  front-end  processing, 
session  services,  terminal  management,  database  management, 
atnd  peripheral  management.  Figure  1.1  introduced  the  logical 
connections  of  this  LAN.  Figure  3.1  presents  a  possible 
physical  connection  configuration. 


Figure  3. 1  Possible  Physical  LAN  Connections. 


This  thesis  also  assumes  a  multiplexed  data/control  bus 
capable  of  supporting  half  and  full-duplex  communications. 
Further,  it  is  assumed  that  the  terminals  connected  or 
potentially  connectable  to  this  L&S  are  hetrogeneous  and 
that  the  hetrogenous  mix  *111  be  in  a  constant  state  of  flux 
during  the  next  decade. 

0.  GEM  ERIC  TH  MODEL 

Given  the  user  requirements,  design  concerns,  and  envi¬ 
ronmental  assumptions  developed  above.  Figure  3.2  presents 
the  author's  attempt  to  meet  these  criteria  with  a  generic 
TH  model. 


Figure  3.2  Generic  Terminal  lanagement  Model. 


Figure  3.2  has  the  following  components: 

1)  A  generic  terminal  with  an  input  capability 
(keyboard,  light  pen,  optical  scanner,  etc.)  and  an  optional 
output  device  (CRT  screen,  signal  light,  teletype,  etc.). 

2)  A  device  or  module  which  cai  understand  the  signals 
coiing  from  the  input  device  and  can  send  signals  to  the 
output  device  which  it  cai  recognize.  This  component  also 
has  a  command  language  of  its  own  which  allows  the  user  to 
design  an  output  display  and  to  map  note  than  one  process  to 
that  display. 

3)  This  component  represents  the  terminal  in  dealings 
with  the  application  process  (one  per  process).  It  also 
builds  and  manipulates  a  terminal  data  structure  for  each 
process. 

4)  This  component  represents  the  application  program  in 
dealings  with  the  terminal  process  (one  per  process).  It 
also  builds  and  manipulates  an  application  data  structure 
for  each  process. 

5)  This  component  sets  the  rules  for  and  format  of 
communications  between  the  terminal  processes  and  applica¬ 
tion  processes  (for  all  processes). 

In  the  most  simplistic  terms  components  3  and  4  are 
attorneys  for  their  clients,  the  terminal  and  the  applica¬ 
tion  program,  respectively.  They,  aid  only  th ay,  know  their 
clients  capabilities  and  expectations.  Both  are  very  strong 
willed  and  therefore  need  an  arbitrator  (component  5)  to 
ensure  that  commun icatins  are  meaningful  and  properly 
coordinated. 

At  this  point  this  model  simply  provides  an  ideal  TH 
whose  generic  components,  if  implemented  ideally,  would 
provide  a  modular  TH  capable  of  meeting  user  requirements 
and  design  concerns  while  having  the  flexibility  to  respond 
to  changes.  A  recommended  specific  implementation  of  this 
model  will  be  presented  in  Chapter  17. 
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E.  TERMIHAL  HAH  AGEHEHI  APPBOACBES 

Approaches  to  TM  can  be  generally  discussed  in  two 
broad,  and  unfortunately  mot  mutuallf  exclusive,  categories; 
parametric  and  virtual  terminal. 

1.  Param°tr ic  Approaga  es 

Generally,  parametric  terminal  protocols  attempt  to 
list  a  set  of  terminal  characteristics  with  each  type  of 
terminal  having  a  different  set  of  parameters  for  each  char¬ 
acteristic.  The  host  computer  may  then  set  tie  parameters 
available  on  that  terminal  to  /alues  needed  for  the 
process/application  [Hef.  12:  pp.  84-86  ]. 

This  approach  is  used  by  the  ARP  A  SET  Telenet 
protocol  and  by  systems  implementing  International 
Consultative  Committee  for  Telephones  and  Telegraphs  (CCITT) 
recommer.dat  ions. 

When  evaluating  these  two  approaches  the  ARPANET 
Terminal  Interface  Processor  (TIP)  is  compared  to  the  CCITT 
Packet  Assembler/Disassembler  (PAD) .  Both  approaches  use  a 
primitive  command  language  to  open  and  close  connections  and 
to  set  terminal  parameters.  The  primary  difference  being 
the  perceived  role  each  plays  in  the  network  architecture. 
In  the  ARPANET  the  TIP  is  a  limited  capability  logical  host 
with  knowledge  of  terminal  parameters.  Whereas,  the  CCITT 
considers  a  PAD  an  integral  part  of  the  network  acting  as  an 
interface  between  data  terminating  equipment  (DTE).  A  DTE 
can  be  either  a  host  or  a  terminal.  [Ref.  12;  pp.  84-86], 
[Raf.  13:  pp.  335-348],  [Ref.  14;  pp.  586-587]. 

The  PAD  cited  in  ZZ ITT  protocols  is  the  most  compre¬ 
hensively  defined  parametric  approacn  to  terminal  handling. 
There  are  three  basic  approved  reco mmendations  covering 
operation  of  the  PAD;  X. 3  which  defiles  the  PAD  itself,  X. 29 
defines  the  interface  between  the  terminal  and  the  PAD,  and 
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X.29  defines  the  interfile  between  the  PAD  and  the  host 

[Ref.  12:  pp.  84-86]. 

The  shortcoming  of  these  approaches  is  that  the  PAD 
protocols  provide  r.o  generic  functions.  They  assume  that 
the  application  in  the  host  knows  what  the  teninal  will  do 
and  that  the  terminal  will  do  what  is  intended  [Ref.  14: 
pp.  586-587]. 

Telenet's  Interactive  Terainal  Interface  (III) 
provides  an  enhanced  sat  if  parameters  which  helps  offload 
soae  of  the  terminal  handling  responsibilities  from  the 
host.  Telenet  offers  a  further  refinement  called  a  virtual 
terminal  which  includes  a  few  generic  functions  on  top  of 
the  ITI  parameters.  Unfortunately,  the  ASP ASET  virtual 
terminal  was  designed  primarily  to  support  scroll-type 
terminals  which  have  much  fewer  parameters  than  more 
sophisticated  page  and  form  mode  terminals.  Although  the 
list  of  parameters  was  extended,  few  of  the  options  (parame¬ 
tric  values)  were  implemented  [Ref.  14:  pp.  586-587], 

Both  these  approaches  are  most  suitable  for 
providing  TM  for  existing  terminals,  the  more  homogenity  the 
better.  To  be  really  useful,  these  functions  should  be 
standardized  so  that  the  host  system  can  rely  upon  a 
PAD/inter  f  ace  with  known  properties.  Even  with  st*  t  >  jriza- 
tior.  the  envolvement  of  the  host  3ys:?m  in  TM  would  still  be 
extensive  or  the  list  of  ? AD/interf ace  parameters  would  be 
enormous  (Ref.  13:  pp.  347-348]. 

As  several  of  the  user  requirements  and  design 
concerns  discussed  earlier  imply  the  need  for  the  greatest 
amount  cf  transparency  achievable  and  further  imply  an 
increasing  number  and  variety  of  terminals,  the  parametric 
approaches  appear  too  limited. 
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2.  Virtual  ler  filial  ££oto;2l2 

Virtual  Terminal  Protocols  (VTP)  hare  undergone 
significant  evolution  since  the  first  VTP  was  placed  in  use 
by  the  ARPANET.  This  (TTP  was  designed  primarily  with 
scroll-mode  terminals  in  mind.  It  is  based  upon  three  basic 
principles;  the  concept  of  a  'network  virtual  terminal' ,  the 
concept  of  negotiation  of  options,  an3  a  symmetrical  view  of 
terminals  and  processes  [Ref.  12:  p.  88]  [Ref.  14:  p.  588]. 
This  first  VTP  laid  very  firm  ground  for  further  sophistica¬ 
tion  of  the  Virtual  Terminal  (VT).  Unfortunately,  although 
the  Telenet  VTP  was  designed  with  fifty-«»ight  parameters, 
very  few  were  actually  implemented.  It  therefore  remains  to 
explore  a  few  more  of  the  many  VTP  approaches  developed 
since  the  ARPANET  VTP. 

A  model  which  focuses  on  page  and  fora  mode  termi¬ 
nals  was  developed  by  Schicker  and  Quenki.  It  is  used  in  the 
European  Informatics  Network  (EIS)  and  is  described  in 
Reference  15  (p.  485).  This  model  is  called  a  data  struc¬ 
ture  model.  In  it  a  data  structure  is  viewed  as  containing 
a  set  of  fields  each  of  which  has  certain  attributes  such  as 
size  of  the  field,  what  type  of  characters  it  contains, 
whether  cr  not  the  field  can  be  modified  by  the  user,  etc. 
This  definition  of  a  data  structure  has  become  widely 
accepted  and  will  be  used  in  the  remainder  of  this  thesis. 
This  model  assumes  that  application  programs  are  written  to 
perform  abstract  operations  on  a  data  structure  and  that  the 
reiote  (user)  process  has  a  similar  data  structure.  The  VT? 
is  the  mechanism  by  which  the  changes  made  by  the  applica¬ 
tion  process  to  its  data  structure  are  passed  to  the  user 
process  so  that  its  data  structure  can  be  changed  accord¬ 
ingly,  and  vice  versa. 
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data  structure 


A  refinement  of  the  data  structure  model  is 
described  in  Reference  13  (  pp.  362-355).  In  this  model  a 
terminal  has  a  data  structure  and  a  controlling  process 
called  a  "T-PAD"  with  a  relationship  much  like  that 
described  in  the  parametric  approach  in  subsection  1  of  this 
section.  Similarly#  the  host  system  has  a  data  structure 
with  which  it  is  designed  to  interact  via  a  controlling 
process  called  an  "S-PAD"  .  The  messages  passed  between 
these  two  "PADs"  to  negotiate  the  data  structure  and  the 
available  commands  to  manipulate  the  data  structure  are 
contained  in  the  VTP.  Tie  appeal  of  this  approach  is  two¬ 
fold;  the  S-PAD  implies  a  NVT  concept  such  as  inscribed  by 
Tanenbaum  in  Reference  15  (p.  423»  ,  where  a  NVT  is  an 
abstract  terminal  the  characteristics  of  which  are  assumed 
by  all  interactive  application  programs;  secondly,  a  symme¬ 
trical  approach  such  as  this  allows  oot  only  the  traditional 
terminal  to  application  interaction,  but  also  terminal  to 
terminal  and  application  to  application  interaction,  giver,  a 
sufficiently  adept  VTP,  The  utility  of  such  capabilities 
can  be  shown  in  a  common  Stock  Point  scenario.  This  scen¬ 
ario  exists  when  an  application  program,  such  as  APADE, 
creates  records  that  are  duplicated  or  entered  into  files 
necessary  to  the  correct  operation  of  another  application 
program,  such  as  IDA.  For  instance,  the  establishment  of  a 
contract,  which  requires  a  record  npdata  in  an  APADE  file, 
also  necessitates  an  update  of  a  financial  record  in  an  IDA 
file.  Such  changes  can  be  made  by  batch  processing  (current 
practice)  or  by  application  to  application  interaction  such 
as  made  possible  by  a  T!1  implementing  this  type  of  model. 

The  approach  above  is  very  similar  in  function,  if 
not  vocabulary,  to  the  NVT  envisioned  for  ARPANET'S  Telenet 
protocol  and  the  IN5JG  VTP.  All  are  deemed  symmetrical  in 
that  each  side  of  a  session  has  its  own  view  of  the  state  of 
the  VT  [Ref.  14:  p.  5  89].  Tnis  as  opposed  to  an 
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asymmetrical  model  where  the  VI  is  considered  only  from  the 
perspective  of  the  application  progras.  In  such  a  model  the 
physical  terminal  is  transformed  by  software  to  appear  as  a 
VT  to  the  application  program  [Ref.  16:  p.  30*].  This 
approach  cannot  support  terminal  to  terminal  or  process  to 
process  interaction  [Ref.  14:  p.  588]. 

In  each  of  the  VT  concepts  described  the  VT’s  are 
supported  by  two  elementary  protocols;  a  virtual  terminal 
display  data  transformation  protocol  and  a  control  protocol. 
The  data  transformation  protocol  maps  display  commands  from 
the  sending  process  into  the  prescribed  input  data  formats 
for  the  receiving  process.  Ihe  control  process  exchanges 
non-display  information  for  coordinating  interactions 
[Ref.  17:  p.  85]. 

A  more  expansive  approach  is  offered  in  Reference 
10.  In  this  approach  three  abstractions  (virtualizations) 
are  proposed;  a  virtual  device,  a  conceptual  data  type 
definticn,  and  a  conceptual  image.  The  virtual  device  is 
considered  an  association  between  a  definition  of  a  struc¬ 
ture  for  a  (device)  data  object  and  a  set  of  operations 
which  are  the  only  means  for  accessing  this  (device)  data 
object.  The  conceptual  data  type  definition  is  a  similar 
association,  but  with  regard  to  the  structure  of  data  and 
the  operations  which  may  be  peformed  on  data  structure 
objects.  The  conceptual  image  is  considered  a  definition  of 
the  means  by  which  a  mapping  of  the  conceptual  data  on  the 
virtual  device  is  obtained.  The  thrust  of  this  concept  is 
that  in  a  hetrogenous  network,  assaaptions  regarding  inden- 
tical  virtual  devices  and  data  structures  may  net  be 
desireable  and  possibly  not  practically  viable.  Only  an 
agreement  of  negotiated  parameters  need  be  known  by  each 
partner.  The  authors  wrote  a  follow-on  article,  [Ref.  18], 
in  which  they  presented  a  detailed  recommendation  of  the 
protocols  and  options  for  each  of  these  virtualizations. 
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All  of  the  above  approaches  require  the  negotiations 
of  options/parameters  to  be  used  in  a  session,  be  they 
device  characteristics,  data  structure  or  commands. 
Negotiations  are  either  asynchronous  or  master-slave  (synch¬ 
ronous)  depending  on  the  symmetry  of  the  interaction  ana  the 
trust  the  designers  place  in  whatever  mechanism  they  may 
have  implemented  to  resolve  negotiation  deadlocks.  The 
literature  regarding  negotiation  algorithms  seems  polarized 
with  each  side  singing  the  praises  of  their  approach.  The 
author's  preference  is  included  in  the  TM  model  presented  in 
Chapter  IV. 

F.  REINHART  AID  ABABA  TN 

In  Reference  1  (p.  5  5),  the  authors  proposed  a  T1 
approach  based  upon  a  "Virtual  Terminal"  management  concept. 
The  primary  feature  of  their  VT  is  that  it  "...  converts  a 
single  physical  terminal  into  multiple  virtual  terminals, 
each  of  which  may  be  written  into  or  queried  for  input".  To 
support  this  concept  the  idea  of  a  user  defined  screen 
configuration  is  proposed.  This  would  allow  a  user  to 
divide  his  screen  into  "windows"  each  of  which  contains  the 
display  of  a  separate  process.  Although  only  one  window/ 
process  would  be  active  at  a  given  moment,  it  is  clear  that 
the  implementation  of  this  concept  would  satisfy  several  of 
the  requirements  and  concerns  addressed  earlier  in  this 
thesis. 

The  thesis  also  discuss  on  page  7h  the  use  of  a  generic 
terminal  transformation  taole.  This  table,  as  proposed  by 
Hillsberg  [Bef.  19]  is  used  to  convert  specific  physical 
terminal  sub- functions  to  generic  commands  and  vice  versa. 

Although  this  thesis  owes  its  roots  to  the  Reinhart  and 
Arana  effort,  subsequent  readings  an3  investigation  have  led 
this  author  to  step  back  from  most  of  the  specifics 
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presented  in  their  thesis  and  nova  toward  a  broader  concept 
for  TM  functional  specification  using  their  concepts  as  an 
inspiration. 


iv.  8!;SSSS8.B4II2Ss 


A.  OVERVIEW 

The  recommendations  contained  in  this  chapter  are  a 
marriage  of  the  generic  Di  model  presented  and  the  variety 
of  specific  approaches  discussed  in  Chapter  ill.  The  result 
is  a  specific  model  consisting  of  components  and  protocols 
interfacing  those  components.  General  recommendations  are 
listed  in  section  B  below.  Section  Z  presents  the  recom¬ 
mended  model. 

B.  GENERAL  RECOMMENDATIONS 

1)  The  TM  should  be  based  upon  the  concept  of  a  NVT. 
Each  application  program  should  be  aole  to  assume  that  it  is 
dealing  with  a  terminal  where  the  default  parameters  will  be 
used  unless  the  user  negotiates  different  parameters  using 
the  NVT  capability. 

2)  The  TM  should  support  the  highest  level  of  abstrac¬ 
tion  technologically  available. 

3)  Negotiation  of  device  definitions  should  be  hierarch¬ 
ical.  Standard  classes  of  terminals  defining  mandatory 
characteristics  (minimum  parameter  values)  should  reside  at 
the  highest  levels  of  the  hierarchy.  Optional  (negotiatible) 
operations  should  reside  at  lower  levels. 

4)  The  TM  should  support  user  defined  screen  format  for 
use  in  both  displaying  multiple  processes  and  designing 
display  and  possible  report  format. 
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C.  RECOHHENDED  TH  HODEL. 

Figure  4.1  presents  the  raraLnal  Management  Model, 
recommended  by  the  author.  The  opponents  are  explained 
below. 


Figure  4.1  Recommended  m  Model. 


1.  Input/Outout  Dev  ire 

A  terminal  is  viewed  as  two  separate  devices.  The 
separation  recognizes  that  a  LAN  say  recieve  input  from 
devices  that  have  no  outpit  capability,  e.g.  light  pens,  DCR 
scanners,  9tc.  The  r?J  must  be  able  to  handle  inputs  fro« 
such  devices.  Additionally,  the  ability  to  transform  and 
coatrol  inputs  is  conceived  to  be  totally  separated  from  the 
ability  to  control  and  aap  output. 
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2.  iaaal  Zi&si&l  Imisal  (lip 

s 

The  function  of  the  LVT  is  to  hide  the  idiosychra- 
cies  of  the  user  terainal  from  the  LAN  and  to  nap  its  data 
structure  and  any  changes  to  that  structure  to  the  terminal 
display  device.  The  LVT  oonsists  of  a  terminal  process  (TP) 
component  and  a  disk-based  terminal  lata  structure  (TDS). 

The  TP  utilizes  a  generic  terminal  transformation 
table  (see  Ref  19)  to  virtualize  terminal  sub-functions  and 
a  hierarchically  organized  set  of  terminal  primitives  and 
parameters  as  discussed  in  paragraph  B.3  above.  The  TP  also 
uses  a  user  defined  map  of  the  scraei  display  for  output. 

The  TP  is  responsible  for  representing  the  terminal 
in  negotiations  with  tha  application  process  (or  another 
TP).  It  is  also  responsible  for  mapping  terainal  input 
commands  to  the  TDS  and  for  mapping  TDS  changes  to  the 
output  unit.  These  functions  are  comparable  to  the  "T-PAD" 
discussed  in  Reference  13  and  Ihaptar  III. 

3.  i&£v°ik  virtue},  latsiail.  (sn> 

The  NVT  is  configured  identically  to  the  LVT  with  an 
application  process  (AP)  in  place  of  the  TP.  The  AP  has  the 
same  data  structure  modifications  responsibilities,  except 
that  it  takes  orders  from  and  reports  changes  to  an  applica¬ 
tion  program  as  opposed  to  a  terminal. 

The  major  conceptual  difference  between  the  NVT  and 
the  LVT  is  that  the  NVT  is  a  parametric  model  of  the  entire 
network's  concept  of  a  terminal.  Its  primitives  and  parame¬ 
ters  are  fixed.  The  application  program's  requirements  are 
met  by  passing  necessary  parameter  values  to  the  AF.  Note 
that  the  number  of  parameters  are  fixed,  but  that  each 
parameter  may  offer  more  than  one  option  (value).  The  AP 
then  represents  the  application  program  in  negotiations  with 
tha  T ?  as  to  what  values  will  actually  be  used.  Obviously, 
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the  AP  will  not  agree  to  any  parametric  values  lower  than 
the  program  requires,  bat  it  may  agree  to  higher  values 
should  the  TP  insist.  The  AP  hides  all  negotiatied  values 
from  the  program  except  those  that  tie  program  expects. 

4.  virtual  Terminal  gcotosal  (HE* 

The  VTP  is  a  message  based  protocol  with  several 
functions,  discussed  here  in  chronological  order.  The  VTP 
controls  the  the  exchange  of  negotiation  messages  between 
the  TP  and  AP.  During  these  negotiations  the  primitives  and 
parameter  values  of  control  messages  are  selected  as  well  as 
the  contents  of  the  data  structure.  The  recommended  negoti¬ 
ation  protocol  will  be  explained  in  the  session  example 
below.  Cnee  all  values  are  set,  the  VTP  becomes  responsible 
for  passing  control  messages  between  the  TP  and  AP  for  the 
manipulation  of  their  respective  data  structures.  In 
fulfilling  this  responsibility,  the  VTP  controls  the 
sequencing  of  messages  according  to  the  communication  method 
selected  during  negotiations,  i.e.,  alternating  or  free- 
running,  and  dictates  the  format  of  these  messages. 

5 •  Session  Example 

a)  The  user  logs  on  his  terminal  identifying  himself 
and  the  terminal  ID.  lerainal  ID  can  be  done  automatically 
if  the  capability  exists. 

b)  The  TP  will  compute  the  command  signals  needed  to 
handle  this  particular  terminal  using  the  transformation 
table.  The  TP  will  then  begin  a  screen  formatting  subroutine 
conversation  with  the  user,  in  which  the  first  user  response 
may  result  in  a  default  screen.  (note:  ashing  the  guestioc 
rather  than  waiting  for  the  user  to  request  screen  format¬ 
ting  should  evoke  curiosity  and  quieten  the  learning  process 
for  this  feature)  This  routine  will  construct  the  output  map 
for  the  TP's  subsequent  interaction  with  the  oueput  device. 
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c)  Once  the  user  has  defined  the  screen  format 
desired,  the  first  (and  possibly  only)  command  to  call  an 
application  program  is  entered. 

a)  The  TP  passes  this  message  to  the  LAN  which  may 
need  to  send  it  out  to  the  long-haul  network. 

e)  The  destination  node  will  establish  an  AP  to 
which  the  application  program  passes  its  terminal  and  data 
structure  requirements.  At  this  point,  and  throughout  the 
negotiation  process,  the  VTP  is  ensuring  one-way 
coimunications. 

f)  Once  negotiations  have  bean  completed,  the  appli¬ 
cation  program  directs  the  AP  to  sat  the  initial  state  of 
its  data  structure.  Upon  doing  so,  the  AP,  using  the  VTP 
message  format,  passes  the  agreed  lata  structure  instruc¬ 
tions  to  the  T?  which  both  creates  an  identical  initial 
state  in  its  data  structure  and  maps  the  data  structure  to 
the  user-defined  screen  format. 

g)  At  this  point  the  VTP  Bay  allow  free-running 
{asychrorous)  communications  if  both  parties  can  support 
such. 

h)  When  the  application  program  is  completed,  the 
connection  is  severed  and  the  TP  begins  its  user  dialouge 
ar.e  w. 

Admittedly,  this  TM  model  is  a  compromise  between 
the  generic  goals  presented  in  Chapter  III  and  the  practical 
implications  of  NAVSOP's  dedication  to  application  programs. 
A  more  esthetically  pleasiig  concept  is  outlined  in  Chapter 

V. 
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v.  ifii  S5S2SSS12IB  &EEEQ4SI! 


1.  THE  ASSUMPTIONS 

The  concept  discussed  ir.  this  chapter  is  a  recommenda¬ 
tion  for  the  future.  It  is  based  or.  the  following 
assumptions : 

1)  NAVSOP  is  willing  to  abandon  the  development  and  use 
of  application  programs  in  favor  of  functional  modules  and  a 
distributed  database  systei. 

2)  NAVSOP  defines  the  set  of  queries  and  reports  it 
wishes  the  system  to  provide. 

3)  NAVSOP  is  willing  to  allow  increased  local  flexi¬ 
bility  ir  the  design  of  display  and  report  formats. 

B.  THE  CONCEPT 

Given  the  above  assuiptions,  the  envisioned  data  base 
system  would  be  built  by  use  of  a  data  base  "designer"  and 
program  generator  such  as  discussed  in  Reference  23  .  The 
basic  tool  of  this  building  process  is  called  a  Hierarchical 
Interactive  Query  (HI-IQ)  language.  The  result  of  this 
process  would  be  a  database  capable  of  supporting  programs 
written  in  a  COBOL  Data  Manipulation  Language  (0 ML)  for  data 
entry  and  inquiry.  The  primary  chars  of  this  concept  is  the 
reduction  of  redundant  record  field;  in  different  applica¬ 
tion  files  and  the  concomitant  reduction  in  required  file 
space.  Given  that  there  are  only  two  primary  fields  forming 
the  backbone  of  the  vast  aa  jority  of  stock  point  and  inven¬ 
tory  control  point  transactions,  the  requisition  number 
(order  number)  and  the  National  Stock  Number  (or  part 
number) ,  the  concept  of  a  hierarchical  data  base  system  to 
support  what  is  now  supported  by  UADPS  file  management 
programs  is  not  so  far-fetched. 
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A  second  enhancement  this  approach  offers  is  the  elimi¬ 
nation  of  the  need  far  application  to  application 
interaction,  be  it  batch  or  interactive.  Because  the  finan¬ 
cial  data  field  for  a  DADPS  requisition  entry  is  the  same 
field  used  in  IDA,  the  need  for  passing  this  information  to 
the  IDA  application  progru  for  entry  is  eliminated. 

C.  TH  IMPLICATION 

Adoption  of  the  systen  described  above  would  not  neces¬ 
sitate  scraping  the  TM  recommended  in  Chapter  IV,  but  tc 
fully  capitalize  on  the  benefits  of  the  system,  certain 
changes  would  be  necessary. 

The  most  important  change  would  be  to  enhance  the 
Terminal  Process  (TP)  by  providing  it  with  a  data  structure 
description  language  whim  would  logically  be  a  subset  of 
the  system's  Data  Manipulation  Language  (DHL)  .  This 
language  would  be  available  to  a  user  to  name  fields  and 
zones  and  for  defining  tae  attributes  and  dimensions  of 
such.  This  capability  would  enable  users  to  easily  design 
screen  and  report  formats  tailored  to  their  needs.  But,  such 
a  capability  would  require  a  rethinking  of  the  application 
program's  master  role  in  establishing  data  structure 
parameters. 

As  this  concept  would  move  away  from  the  application 
emphasis  on  form  or  page  da  signs  in  data  structures,  changes 
would  also  be  necessary  in  NVT  and  VTP  parameters.  3oth 
could  be  simplified  because  they  wouLd  not  nave  to  be  struc¬ 
tured  to  support  a  myriad  of  often  conflicting  application 
programs. 

Should  the  assumptions  in  section  A  evolve  ,  the  concept 
outlined  in  this  chapter  is  strongly  recommended  for  further 
study. 
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